This sounds useful. I'd also be happy to put it in SWP as well or instead.

@cwebber Is there any reason why the reverse (AP-to-WF) lookup can't just pass the ActivityPub URI as the resource param of the WebFinger endpoint? That would seem like a really clean way to do the translation if the WebFinger spec allows it.

Example:

WF-to-AP: /.well-known/webfinger?resource=acct:evan@mastodon.social
AP-to-WF: /.well-known/webfinger?resource=http://mastodon.social/@VamptVo

Some of this was covered during the original WebFinger discussion (#20). Suggestion:

If the user enters an acct URI:

• Do webfinger discovery for that resource with rel=self
• If a rel=self type=application/ld+json;profile=<AS2 profile> link exists, follow that
• If a rel=self link with no type exists, follow that

Servers SHOULD return one of the acct: URI or the AS2 URI in the subject member of the returned JRD. They MUST return the other in the aliases member, or both if neither is the returned subject.

For advertising a WebFinger-esque handle in a profile:

• Add a link rel=me href=acct:username@host.tld link to the profile (in AS2, this would be represented as an url: {} entry)

The exact rels to use is an interesting question. rel=self is defined by Atom; rel=me is from XFN. I'm more unsure about rel=me than rel=self for this.

Examples:

GET /.well-known/webfinger?resource=acct:kenzoshii@example.com&rel=self
Host: example.com

HTTP/1.1 200 OK
Content-Type: application/jrd+json

{
"subject": "https://kenzoishii.example.com/",
"aliases": ["acct:kenzoshii@example.com"],
"links": [
{"rel": "self", type="application/ld+json; profile=\"https://www.w3.org/ns/activitystreams\"", href="https://kenzoishii.example.com/"}
]
}

GET /
Host: kenzoshii.example.com
Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams"

HTTP/1.1 200 OK
Content-Type: application/ld+json; profile="https://www.w3.org/ns/activitystreams"

{
  "@context": ["https://www.w3.org/ns/activitystreams",
               {"@language": "ja"}],
  "type": "Person",
  "id": "https://kenzoishii.example.com/",
  "following": "https://kenzoishii.example.com/following.json",
  "followers": "https://kenzoishii.example.com/followers.json",
  "likes": "https://kenzoishii.example.com/likes.json",
  "inbox": "https://kenzoishii.example.com/inbox.json",
  "outbox": "https://kenzoishii.example.com/feed.json",
  "preferredUsername": "kenzoishii",
  "name": "石井健蔵",
  "summary": "この方はただの例です",
  "icon": [
    "https://kenzoishii.example.com/image/165987aklre4"
  ]
  "url": [
    {"rel": "me", "href": "acct:kenzoshii@example.com"}
  ]
}

Servers probably MUST NOT trust any rel=me URIs with different host parts without verification for obvious reasons.

(Oh, and for user entered IDs which aren't valid URIs: Suggest normalization as per OpenID Connect Discovery)

We talked about this on the call; it doesn't seem like this needs to go into the standard proper, since there seem to be good ways to infer the right behavior. (If somehow a property is really needed, it could be an extension, but it isn't looking like it is to make this work.) However, we should have a good wiki page for this and try to encourage consensus around the groups coming from WebFinger directions on what the right approach is.

I'm not sure what page would be the best to use, whether it should be under the Socialwg namespace or something else (the upcoming community group?)

I like the idea of using webfinger to find out the information in both directions btw!

New wiki page about this: https://www.w3.org/wiki/ActivityPub_and_WebFinger

Any idea what the rel should be when linking to an AS2 representation of a resource? @oshepherd suggested self. Is that the correct way to do it? I guess most clients can figure it out based on type even if they didn't know the right rel.

@evanminto rel=self seems like it may be right? #204 seems kinda relevant to that convo.

BTW I'm tagging this with "postponed" but not closing it yet, mainly because good conversation still seems to be happening.

RFC4287 (Atom) says

3. The value "self" signifies that the IRI in the value of the href
   attribute identifies a resource equivalent to the containing
   element.

If we interpret it as
<acct:foo@example.com>[rel="self" type='application/ld+json; profile="https://www.w3.org/ns/activitystreams";] <http://example.com/~foo>

then the relationship seems appropriate - I am looking up the person "foo@example.com" and their description is here

--
With regards to linking from HTML files (as per #204), I'd encourage rel="alternate". Rationale:

• Precedent: This is how Atom feeds indicate the location of the HTML representation of an entry (<link rel="alternate" type="text/html" href="..."/>. This is also used for Atom & RSS feeds, which while squiffy (hence why rel=feed now exists), is accurate in the context
• WebSub establishes a constraint that there can only be one rel=self link on a resource which is to be subscribed to. Contradicting another W3C spec - especially one from the same WG - would seem to be poor form.
• It is inaccurate to classify an AS2 representation as equivalent to a HTML representation. Transformation between the two is likely to be lossy in some manner.

One thing to consider regarding Webfinger is the syntax and aesthetics:

Something I heard a lot from new users, during the early days of Mastodon, was that they hated that handles had 2 @s. It doesn't look very good and also makes it strangely similar to email. I can give you "@datapup_" and that's pretty clear it's Twitter. "@shel@icosahedron.website" looks like an email (which makes sense since it's WebFinger) but that makes it seem like I'm telling you to email me, not to follow me. So I tell people "Follow me on Mastodon" but like, then I have a friend who is on GNU Social; they're not following me on Mastodon, they're follow me on GNU Social. As the number of federated softwares using the same protocol increase, it becomes increasingly difficult for the layman to understand that something is the same network. "Follow me on the OStatus Fediverse" is very not catchy and "ActivityPub-Compliant Social Media" is... even less so.

Another issue that came up is that if you share your WebFinger handle on twitter or other social media, it tags the domain as a user. Every single time someone says "Follow me I'm @datapup@mastodon.social" it tags the user @mastodon on twitter. We actually got complaints from twitter users saying that we were harassing them and requested we change the second @ to something else so people would stop tagging them if they happened to have a common domain as their username (@mastodon @awoo @toot @pouet etc. are all domain domains with various .tlds). Unfortunately there was nothing that could be done because OStatus uses WebFinger and WebFinger uses 2 @s. "You'll have to get twitter to change this because there's nothing we can do at this point, the protocol is already written."

WebFinger compatibility is useful for compatibility with other federated systems, so it may be that the @name@domain.tld syntax is here to stay. If it is possible to use an alternative syntax, such as @user:domain.tld @user>domain.tld @user.domain.tld @user\domain.tld or @user!domain.tld (really anything intuitive) it would resolve some issues and satisfy the end-user's desire for aesthetics as well as make it very apparent from syntax that it is not an email.

This is a relatively minor comment though. Like I said, if double @ syntax is how it's gotta be then I think the world will manage. I just figured since we're building a protocol, now would be the time to bring this up so we don't end up with another situation like we did earlier where when users brought up issues with the syntax all we could say was "well, it's already the protocol, too late to change it"

Something of a third option is @domain.name

This seems important for any business or entity that's actually known by a domain name. If you're United Airlines, you don't want to be tooting as @united@united.com or @pr@united.com or something. It'd be much cleaner, perhaps clean enough to be tolerable, to be @united.com.

I don't think the user-faces sides of the protocol are really frozen, but it would take significant effort to get everyone moving in the same direction.

I'd think a reasonable path forward is suggest UIs support all three @user@host.domain, @domain.name, and URLs. Maybe allow the @ before URLs. Maybe allow URLs to be abbreviated, dropping the 'https://'. Let people use any of these for mentions & "follow me at", and make sure they all work. When I use any while composing a post or searching, the system should dereference and confirm what I'm talking about.

Then time will tell what wins out.

Note that the leading @ isn't really a part of any protocol syntax; it's more convention, originally established by Twitter and now popularised elsewhere (e.g. Facebook uses a leading @ to indicate you're tagging a person, Github does the same, etc; but in the Facebook case the @ isn't displayed and there's no reason an implementation couldn't do similar)

The OpenID connect canonicalization algorithm I mentioned above handles "user@domain.name", "domain.name", "domain.name/foo" and similar formats (I'm omitting the leading @ here - you might use it as an introducer, but it's kind of unnecessary depending upon your system's UI). Running the algorithm will canonicalize those three into

• acct:user@domain.name
• https://domain.name/
• https://domain.name/foo

The first is an acct: URI, so you'd need to do WebFinger discovery. For the others, you can "follow your nose" (Request with Accept: activitystreams and, if that fails, scrape for http Link headers or HTML tags with rel=alternative type=activitystreams)

A client could easily take the entered URI and replace it with a display name and link if it wanted.

That sounds great to me (under the circumstance). So the question may be how we gather consensus around doing this canonicalization, and wf if necessary. Do we want some kind of W3C Note explaining how to do this, or make it part of AP, or ... what?

@oshepherd Do you know how the OIDC standards process works? How stable is that spec? Is there a test suite, implementation report, etc?